home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / cat / cat-minutes-92mar.txt < prev    next >
Text File  |  1993-02-17  |  14KB  |  420 lines
  1. These Minutes are a rough draft only - Megan 04/03/92
  2.  
  3. Common Authentication Technology (CAT) meeting minutes, San Diego IETF, 16-17 
  4. March 1992
  5.  
  6. [Note: Jeff Schiller took an additional set of meeting notes which include 
  7. pictures and which are available (in PostScript form) by anonymous FTP
  8. from bitsy.mit.edu with pathname: /cat-ietf/cat-wg-mar92-jis-picurenotes.ps ]
  9.  
  10. The March CAT meetings included discussion of standards advancement plans, and
  11. of interface extension requests made by ICL in support of ECMA  authorization
  12. architecture.  Most of the discussion was spent, however, on the evolving
  13. topic of a unified Internet authentication mechanism hybridizing Kerberos
  14. secret-key and DASS public-key technologies.
  15.  
  16. STANDARDS AND ROLLOUT PLAN
  17.  
  18. John Linn led a standards plan discussion, the result of which was a decision 
  19. to recommend the GSS-API interface specifications for advancement to proposed
  20. standards.  We anticipate that Kerberos and DASS specifications, as well as a
  21. specification  for the planned unified mechanism, will follow in succession
  22. onto the standards track.
  23.  
  24. Two previously-cited technical topics regarding GSS-API were raised  in this
  25. discussion:  (1) the prospect of additional interfaces oriented to
  26. stream-oriented integration (as with UNIX(tm) sockets), tabled as being
  27. separately definable later in an upwardly-compatible fashion, and (2) the
  28. prospect of adding callouts so that user input (e.g., for passwords or
  29. hand-held authenticator information) could be collected at context
  30. establishment time. (2) was tabled because of lacking implementation
  31. experience, possible OS-specificity of approaches, and consideration that such
  32. data might more securely be acquired through end system trusted path facilities
  33. than via application mediation.
  34.  
  35. ICL COMMENTS AND ECMA SECURITY ARCHITECTURE
  36.  
  37. P. Rajaram stood in for Piers McMahon of ICL (who was unable to attend the 
  38. meeting) in leading a discussion based on Piers' message as forwarded to the 
  39. mailing list. Piers' message proposed interface extensions (GSS_Modify_Cred 
  40. and GSS_Get_Attributes primitives) to support authorization features of the 
  41. ECMA security architecture (as described in ECMA reports TR/46, TR/138), and 
  42. Raj presented an overview of that architecture, the slides from which are
  43. included as an appendix to these minutes. Interest was expressed in the
  44. prospect of having the ECMA reports available in FTP-accessible on-line form. 
  45.  
  46. In group discussion, it was recognized (consistent with discussion at the SAAG) 
  47. that specific authorization support features, and related extensions in support
  48. thereof, would comprise a likely area for future IETF security work.  Such
  49. work would consider not only ECMA inputs but  also contributions from the
  50. Kerberos community as well as other sources, selecting an approach or defining
  51. a core intersection of multiple approaches. Any and all relevant inputs would
  52. be solicited.  As with other Internet standards, prototyping results would be
  53. necessary for advancement. Lacking a concrete Internet community decision to
  54. adopt the ECMA architecture, no decision to incorporate the ECMA extension
  55. requests at this time was taken. Raj suggested that it might be useful to
  56. convene a BOF at a subsequent IETF meeting to further familiarize interested
  57. IETF participants with the ECMA architecture. 
  58.  
  59. Specific points raised in ECMA-related discussion: To acquire a Privilege
  60. Attribute  Certificate (PAC), a subject contacts a server.  The PAC contains a
  61. sequence  of attribute triples {type, authority, value} which govern the ways
  62. in which the PAC can be used, and an audit ID which alows audit accountability
  63. for actions independent of the privileges on which access controls are based,
  64. among other elements.  Confusion was expressed about the circumstances under
  65. which a PAC must be confidentiality-protected in transfer, and about whether 
  66. concurrent and separate authentication was necessary in order to demonstrate 
  67. oneself as an authorized user of a particular PAC.  Some of the answers were 
  68. thought to depend on the particular attributes bound into the PAC, per 
  69. definitions in ECMA TR/138.  
  70.  
  71. UNIFIED AUTHENTICATION MECHANISM
  72.  
  73. John Linn gave an overview of goals for the effort, Charlie Kaufman and Cliff 
  74. Neuman presented alternative technical options, and Jeff Schiller led a 
  75. discussion to collect requirement and priorities inputs to be considered in 
  76. selecting among available alternatives. 
  77.  
  78. OVERVIEW OF EFFORT
  79.  
  80. John's overview slides contained the following points: 
  81.  
  82. DASS-Kerberos Unification: How Did We Get Here?
  83.  
  84. - Cross-mechanism portability addressed in CAT
  85.  
  86. - Suggestion at Santa Fe SAAG: support universal interoperability for strong
  87. Internet authentication
  88.  
  89. - Kerberos and DASS designers and architects met in a series of interim
  90. meetings
  91.  
  92. Where are we going?
  93.  
  94. - Internet-Draft documentation of hybrid mechanism to fit under CAT/GSS-API
  95. framework
  96.  
  97. - Ability to migrate applications from already-defined mechanisms to hybrid
  98. when available
  99.  
  100. - Common token format which can accommodate both public-key and secret-key
  101. authentication processes
  102.  
  103. Premises
  104.  
  105. - Domains and endpoints can be built native to Kerberos-like secret-key and
  106. DASS-like public-key technologies; all endpoints can interoperate
  107.  
  108. - Support for user, host, and process principals, represented by
  109. cryptographic keys
  110.  
  111. - Global naming (plan: X.500 Distinguished Names as basis within mechanism),
  112. trust path tied to naming hierarchy
  113.  
  114. Goals
  115.  
  116. - PEM X.509 certificate infrastructure usable as a basis for scaling
  117.  
  118. - Domains equipped with public-key technology can operate without establishing
  119. on-line authentication servers
  120.  
  121. - Domains can be constructed without public-key technology
  122.  
  123. - Self-sufficient startup: can form a domain in isolation and later incorporate
  124. it into the broader hierarchy
  125.  
  126. - Can transport user-provided data (undefined by us) restricting the use of
  127. authentication tokens
  128.  
  129. - Avoid need for endpoints to contact foreign-mode support servers  (KDCs,
  130. certificate stores, ...)
  131.  
  132. Strong Authentication
  133.  
  134. - Successful authentication requires either:
  135.  
  136. --  current possession of principal's key
  137.  
  138. -- principal's authorization to act for principal with other (short-term)
  139. key + demonstration of that key
  140.  
  141. - Intercepted tokens can't be used by attackers to build new tokens for 
  142. masquerade, or be successfully replayed outside narrow window
  143.  
  144. Four Directions
  145.  
  146. - (We believe all can be made to work, and seek to resolve priorities 
  147. and tradeoffs)
  148.  
  149. -- SK endpoints add complexity to interwork with PK
  150.  
  151. -- PK endpoints add complexity to interwork with SK
  152.  
  153. -- "Client makes right"
  154.  
  155. -- "Server makes right"
  156.  
  157. Issues and Tradeoffs
  158.  
  159. - Interoperability with existing/emerging technology bases
  160.  
  161. - What entities can accommodate complexity and performance demands?
  162.  
  163. - What entities can and can't be changed feasibly?
  164.  
  165. - What entities must perform what crypto-functions?
  166.  
  167. ALTERNATIVE TECHNICAL APPROACHES
  168.  
  169. Charlie noted that support for interoperability between Kerberos-native and 
  170. DASS-native authentication peers wasn't (unlike cross-mechanism portability) a
  171. chartered goal  of GSS-API, and that it was a positively surprising result to
  172. discover upon investigation that such support within a unified mechanism below
  173. the interface in fact appeared to be possible, via any of several approaches. 
  174. We confirmed the fact that the ability to support global scaling was intended.
  175.  
  176. Charlie's presented approach has the following characteristics:
  177.  
  178. - SK endpoints need not perform RSA operations or communicate with 
  179. certificate stores
  180.  
  181. - PK endpoints need not communicate with KDCs and the security of 
  182. authentication between PK endpoints cannot be compromised by faulty KDCs 
  183.  
  184. It imposes the following impacts on particular system components:
  185.  
  186. - no impact on SK client
  187.  
  188. - PK clients and servers must be able to end treewalks at a GKDC and use that 
  189. GKDC's key in token generation and processing
  190.  
  191. - SK server must interact with KDC to process incoming tickets arriving from 
  192. PK domains
  193.  
  194. - GKDC must be able to create and open PK tickets
  195.  
  196. The fact of crossing from a public-key to a secret-key domain (or vice versa) 
  197. needs to be determinable in a trusted fashion; naming prefix rules play an 
  198. important part in this determination. 
  199.  
  200. Cliff Neuman began the second CAT session by presenting an approach which
  201. matched Charlie's for the case of an SK client accessing a PK server, using
  202. tickets signed with the private key of a GKDC and integrable into the unified
  203. ticket format.  It was observed that adoption of the unified format (in
  204. contrast, e.g., to use of Kerberos V5 tokens for SK cases) would require some
  205. level of change to all presently-extant peer systems.
  206.  
  207. Cliff presented an alternative approach for the case of a PK client accessing a 
  208. SK server.  A goal of this alternative was to avoid the need for a SK server to
  209. contact the GKDC, since such communication requires that the SK server be
  210. stateful in a manner divergent from the current Kerberos operational model. 
  211. Cliff's proposal included a "Gateway Certificate Distribution Center" or GCDC,
  212. to which PK clients would DASS-authenticate and would receive, in response, a
  213. Kerberos ticket for the target SK server along with an associated encrypted
  214. session key.  The GCDC, not the target server, would mediate interactions with
  215. intermediary SK authentication servers.  In order to support both SK->PK and
  216. PK->SK accesses under this model, both GKDCs and GCDCs would be required; while
  217. these functions are logically distinct, they could likely be colocated. 
  218.  
  219. Cliff summarized the impact which his proposal would impose on particular
  220. system components as follows:
  221.  
  222. - no impact on SK client
  223.  
  224. - PK client must use different protocol in interacting with the last CDC in an
  225. outbound chain
  226.  
  227. - no impact on SK server
  228.  
  229. - PK server impact equivalent to Charlie's proposal
  230.  
  231. - GKDC and GCDC must be able to create and open PK and SK tickets on behalf of
  232. clients
  233.  
  234. REQUIREMENTS/PRIORITIES EVALUATION
  235.  
  236. Jeff Schiller led a discussion at the end of the meeting with a goal of
  237. soliciting group inputs on requirements and priorities for the unified
  238. mechanism.  We created a comparison matrix, and the exercise's results served
  239. to validate many of the assumptions adopted by the designers.  In particular,
  240. the group showed popular acceptance for the idea of a dual-mode approach which
  241. employs PK and SK techniques for different cases.  It was noted that allocation
  242. of computationally-intensive functions among components would be an additional
  243. useful metric, though not one which was included within this analysis. 
  244.  
  245. Criteria included:
  246.  
  247. - free availability of software, in terms of licensing, anonymous FTP-ability
  248. (ranked #3 criterion)
  249.  
  250. - availability of source code implementations (ranked #2 criterion) 
  251.  
  252. - ability of approach to scale to world (by a broad margin, ranked as #1
  253. criterion)
  254.  
  255. - avoidance of on-line trusted KDCs (ranked #4 criterion)
  256.  
  257. - simplicity/elegance of approach (construed by some attendees as equivalent to
  258. verifiability of protocol)
  259.  
  260. - client simplicity (ranked #5 criterion, more important than server
  261. simplicity)
  262.  
  263. - server simplicity
  264.  
  265. - compatibility with existing Kerberos (relatively low priority)
  266.  
  267. - compatibility with SPX (lower priority than Kerberos compatibility)
  268.  
  269. APPENDIX: P. RAJARAM SLIDES ON ECMA SECURITY ARCHITECTURE
  270.  
  271. -----1-----
  272.  
  273. rajaram@sun    speaking-for     piers-mcmahon@icl
  274.  
  275. Motivation:
  276.    - Extend GSS-API to enhance
  277.     . Authorization (useful to Kerberos-5)
  278.     . Delegation  (more than just ON/OFF)
  279.  
  280.    - Strategy
  281.        . Don't modify existing API
  282.        . Add a few new interfaces
  283.  
  284. -----2-----
  285.  
  286. SUMMARY of ECMA SECURITY ARCHITECTURE
  287.  
  288.    - European Computer Manufacturers Assoc.
  289.  
  290.    - This framework developed by a working group
  291.        TC-32 / TG-9
  292.  
  293.    - Supports many security models
  294.        . ACL based
  295.        . Capability based
  296.        . Label based (MAC)
  297.       & . Extensible combinations of above
  298.  
  299.    - 10 security facilities
  300.        . promote modularity
  301.        . support interdomain security
  302.        . allow interoperability
  303.  
  304. -----3-----
  305.  
  306. The 10 SECURITY FACILITIES
  307.  
  308.     . Authentication Service
  309.     . Privilege Service
  310.     . Subject Sponsor
  311.     . Cryptographic Service
  312.     . Secure Association
  313.     . Authorization Service
  314.     . Interdomain Service
  315.     . Audit
  316.     . Security Recovery
  317.     . Security State
  318.  
  319. -----4-----
  320.  
  321. Subjects and Objects
  322.  
  323.    Subjects access Objects
  324.     
  325.    Subjects and Objects have Security Attributes
  326.  
  327.     Subject Privilege Attributes
  328.         . Identity, Group
  329.         . Role
  330.         . Clearance
  331.  
  332.     Object Control Attributes
  333.         . ACLs
  334.         . Information Labels
  335.         . Classifications
  336.  
  337.    Ultimately, access is granted only if the Subject's
  338.    privilege attributes "dominate" the Object's control
  339.    attributes.
  340.  
  341.  
  342. -----5-----
  343.  
  344. Privilege Attribute Certificate
  345.  
  346.     Contains:
  347.         . a Sequence of Attributes
  348.             { Type, Authority, Value }
  349.     . Validity times
  350.     . Contained PACs
  351.     . Audit identity
  352.     . Signing Authority name (Domain authority)
  353.     . Signature
  354.  
  355.     The last two are required.
  356.  
  357. -----6-----
  358.  
  359. Simple Model
  360.  
  361.     +-----+
  362.     | APS |    Authentication and
  363.     +-----+    Privilege Service
  364.       ^  |
  365.      Auth |  | PAC
  366.       |  v
  367.     +---------+                +--------+    
  368.     | Subject |------------------------>| Object |
  369.     +---------+ \        PAC        +--------+
  370.              \
  371.               \                +--------+
  372.                \------------------->| Object |
  373.                 PAC        +--------+
  374.  
  375.  
  376.     1) Subject authenticates itself to APS
  377.     2) Subject receives PAC
  378.     3) Subject offers PAC to Object and receives requested
  379.         service.
  380.  
  381.     A PAC contains both Identification AND Authorization info.
  382.  
  383.  
  384. -----7-----
  385.  
  386.     . A PAC need not contain a Subject Identifier.
  387.     . An anonymous PAC may contain only a security
  388.       clearance, and an audit ID.
  389.     . This may be enough to authorize access.
  390.  
  391.     . Kerberos 5 and Kerberos/DCE can benefit from proposed API
  392.  
  393.  
  394. -----8-----
  395.  
  396. Proposed API (greatly simplified)
  397.  
  398.     GSS-Modify-Credentials
  399.         . [In]     Cred handle
  400.         . [In]     { Attributes & Values} ...
  401.         . [In/Out] Credentials
  402.  
  403.     GSS-Get-Attributes
  404.         . [In]       Cred handle
  405.         . [In]       Requested Attributes
  406.         . [Out]    Returned {Attributes & Values}
  407.  
  408. -----9-----
  409.  
  410. Discussion:
  411.  
  412.     . GSS-API:  for authentication only ?
  413.     . Allow for ECMA, in addition to Kerberos & DASS ?
  414.  
  415.     . CAT --> CAAT
  416.  
  417.     . ECMA BOF ?
  418.  
  419.  
  420.